System and method for generating a code execution timeline from an executing program

ABSTRACT

The present technology is directed to a non-limiting system and method for generating an abstract code execution timeline from repetitive programs, such as video games and simulations. As a non-limiting example, a statistical sampling profile is first taken of the running program, and then the data is converted into several representations. By selecting representative functions based on sampling frequency and call tree hierarchy and then sorting those functions chronologically and hierarchically, an abstract code execution timeline can be generated that summarizes execution within a single repetitive time period, such as a video frame. This timeline is called “Story Mode” since it tells a story of how the program executes over the course of a frame. This abstract code execution timeline can then be used to facilitate program comprehension, primarily for the purposes of modifying the code to improve execution speed.

BACKGROUND

Timelines can be useful in helping a person to understand what happenedover a period of time. A timeline can be used to show events inchronological order. For example, Facebook® employs a timeline to show auser's social events over the course of months or even years. Frompictures to user posts, the events posted on the timeline tell a story.For example, a post of a couple holding a new-born baby shows that theirchild has recently entered the world and the family is now one personlarger. A post of a person holding a diploma could indicate that shejust graduated and received a degree. The timeline shows these eventsand can describe previous events that led up to a current event.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description is set forth with reference to the accompanyingfigures:

FIG. 1A shows example illustrative repetitive software processing;

FIG. 1B is an example diagram showing an illustrative timeline forfunctionality being executed in a frame of a program;

FIG. 2 is a block diagram showing an illustrative implementation of asoftware analysis system;

FIG. 3 depicts an illustrative example of a collection of functions froma profile;

FIG. 4 depicts an example of a collection of functions from a profilethat sorted chronologically and hierarchically;

FIG. 5 illustrates an example of a collection of functions from aprofile that exclude similar children;

FIG. 6 depicts an example of a collection of functions with an includeparent option disabled;

FIG. 7 depicts an example of a collection of functions with an includeparent option enabled;

FIG. 8 is an example embodiment of a flowchart depicting the overallsoftware analysis implemented via the present technology;

FIG. 9 is an example embodiment of a flowchart showing a selection offunctions based on a highest number of inclusive samples duringprofiling;

FIG. 10 is an example embodiment of a flowchart showing processes forexcluding similar children during tree traversal;

FIG. 11 is an example embodiment of a flowchart showing processes forexcluding similar parents during tree traversal;

FIG. 12 is an example embodiment of a flowchart depicting a selection offunctions within an inclusive range during profiling;

FIG. 13 depicts an example of a function with multiple sample runsacross multiple frames;

FIG. 14 depicts an example of a function with multiple sample runsacross multiple frames;

FIG. 15 illustrates an example embodiment of a flowchart for a processfor detecting the start time and end time of a run for a particularframe for each function; and

FIG. 16 depicts an example embodiment of a flowchart for a process ofcomparing two functions to create a sorted list.

DETAILED DESCRIPTION OF EXAMPLE NON-LIMITING EMBODIMENTS OF THETECHNOLOGY

Although may be not as exciting as real-life events, a running softwareprogram also has an important story to tell. This story can be used by asoftware developer to figure out what happens and when it happens. Itcan be very useful in “debugging”—finding and removing errors andinefficiencies. A running software program sometimes calls variousfunctions and accesses various resources such as memory locations. Whichfunctions are called when and which memory locations are accessed when,for example, can tell a story about how the program operates and what itis doing. One can understand a Facebook® timeline for a single person byviewing the user's page. But, understanding group behavior based onhundreds, or even thousands of different timelines, can be very complex.Just as the collection of hundreds or thousands of timelines would relayvery little readily useful information to someone, similar challengesface conventional technology that profiles software using timelines.Some technology has used timelines to help visualize software execution.See e.g., Techniques for Visualizing Software Execution by Seyster(March 2008). But as software and hardware have become more complex,such timelines have become less useful. In particular, CPUs now processmany concurrent functions which can embody millions of instructions persecond, and multi-core processing can process many functions inparallel. These complexities create significant challenges for usefuland effective visualization. The technology described herein helpsaddress these complexities and improves upon prior techniques.

The present disclosure is directed to a non-limiting system and methodfor generating an abstract code execution timeline. In some embodiments,the described techniques can be used to generate the timeline fromrepetitive programs, such as video games and simulations. As anon-limiting example, a statistical sampling profile or series of“snapshots” of program execution is captured for the running program,and then the data is converted into several representations. Byselecting representative functions based on sampling frequency and calltree hierarchy and then sorting those functions chronologically andhierarchically, useful and readable abstract code execution timelinescan be generated that summarize execution within a single repetitivetime period, such as the display of a video frame. This timeline featurecan be called “Story Mode” since it tells a story of how the programexecutes over the course of a frame or other time period. This abstractcode execution timeline can be used to facilitate program comprehension,e.g., for the purposes of modifying the code to improve execution speed.

This present technology uses the data from a statistical samplingprofile to improve upon conventional software profiling technology. Whenthe computer program is repetitive, the non-limiting, example techniquesdisclosed can be particularly useful to discover representativefunctions that can be specially ordered to give an informative timelineexplanation of the running program.

In various software systems, such as video game and simulation programs,code executes periodically, such as at the simulation or video refreshframe rate. Within each simulation or video frame, it is expected to seea pattern of work from the beginning of the frame to the end. Someexamples of this pattern of work would be to read inputs, simulate agentbehavior, simulate physics, resolve collisions, and render the scene.

The timeline display of the present technology has many advantages overconventional software visualization technology. As can be seen in theprogression of FIGS. 3-7, the timeline display sorts and filters theexecuted functions during a frame of program execution. The displayessentially reads left to right over time but also from top to bottombased on the chronological and hierarchical execution of the program.For example, the listing of functions from top to bottom in FIG. 4 showshow each function executes chronologically over time as well as thehierarchical parent-to-child arrangement of the functions.

This display gives the viewer an idea as to which functions executefirst and most often as well as which functions have a “greater”hierarchy based on the parent-to-child relationship between thefunctions. Using FIG. 4 as an example, the eye of the viewer travelsboth left to right and top to bottom in a diagonal direction along thevisualization. Thus, much like a well taken photograph, the eye of theviewer is captured by the visualization.

By sorting the functions chronologically and hierarchically fromleft-to-right and top-to-bottom, the viewer also gets a better idea ofthe depth of program execution. In the example shown in FIG. 4, theprogram depth is shown as the functions descend from A to JJ. Thevisualization can show a greater or lesser program depth based on howfar the grouping of functions descends.

The visualization of the present technology also shows clusters ofprogram execution. For example, FIG. 4 shows execution of Functions A,B, and C during Frame FR where these functions execute the majority ofthe frame. As these functions are executing, several “sub” functionsexecute over time as well where the functions form clusters in thedisplay. For example, in FIG. 4, during the execution of time period1009, a cluster of “sub” functions K, U, GG, and LL execute. This couldindicate to a viewer that functions A, B, and C are allcalling/accessing “sub” functions K, U, GG, and LL during time period1009 and that the “sub” functions may also possibly call each otherduring this time. As can be seen in FIG. 4, for example, the clustersalso appear in descending order from left-to-right over time. Thus, thevisualization once again shows the depth/breadth of program executionover a frame of display. The visualization could also be modified toshow execution of the program over multiple frames of display so thatthe viewer can see the depth of program execution during each from overthe multiple frames. These advantages are described in further detailbelow with respect to the examples shown in the drawings.

FIG. 1A is an example diagram showing illustrative functionalityexecuted in a given period such as a frame of a program (e.g., such as avideo game or game display program). Many software applications repeatexecution of a main overall loop once for each frame of videoproduction. This is especially true for video game simulations and otherapplications which repetitively generate images at periodic timeintervals, but also is true for many other programs that are event ortimer driven.

In its very simplest form, an illustrative main game routine is composedof two very generic loops: update game space and update audio/videoprocessing. In most cases, a main game loop will likely consist of moreelements including, but certainly not limited to, a game updatefunction, a physics engine function, an input/output processingfunction, and/or a display/audio update function, as illustrated in FIG.1A.

FIG. 1B shows an example of a timeline of events for an example,non-limiting game loop during execution of one frame of the loop. In theexample shown in FIG. 1B, the game loop has a “game engine” function, a“physics engine” function, an “input/output processing” function, and an“update display” function. It should be appreciated that each of thesefunctions may access one or more sub-functions (i.e., child functions)which, in turn, could also have one or more sub-sub-functions.

In the example shown in FIG. 1B, frame execution occurs from timeT₀-T_(n) where the one or more functions in the main game loop areexecuted. For example, from time T₀ to T₃ the “input/output processing”function will execute, from T₃ to T₇ the “game engine” function willexecute, from T₇ to T₉ the “physics engine” function will execute, andfrom T₉ to T_(n) the “update display” function will execute. FIG. 1Bthus shows a simplified example non-limiting timeline of a main gameloop executing over one frame of a video game.

It should be appreciated that, especially in modern gaming, the maingame loop will access several functions which in turn have multiple“child” functions. Thus, over one frame of execution, dozens to hundredsof functions may be called. It would be advantageous to provide a systemthat can, among other benefits, organize the various functions that arecalled in a manner that tells a story about the execution of the programduring one or more frames.

With any computer program, a statistical sampling can be recorded withvery little impact on performance. By periodically stopping the programmany times a second, the current call stack can be recorded each timeand then the program can be allowed to run again. Sometimes known as asampling profile, this data set can be used to extract usefulinformation about the running program, such as a list of functions thatrun most often, thus taking up most of the available CPU time.

The present technology aims to automatically curate a select list offunctions and order them in such a way, along with their data, as togive insight into how the program executes inside an individual frame orother repeated task. This final sorted list of functions and associatedgraphs provides an abstract understanding of the program execution, thussimplifying the recorded execution of thousands of functions down to aselect ordered few. The result tells a “story” of the execution within aframe of display, which can be easily understood, even by people who areunfamiliar with the code.

FIG. 2 is a block diagram showing an illustrative non-limitingimplementation of a video game system 1, which can include, for example,an embedded computing device. System 1 runs functions such as the onesshown in FIG. 1 while also providing analysis. The system 1 includes acomputing system 10 connected to a display 12 (or display device 12) andan input device 14. The computing system 10 includes a processor 16,which can execute a video game program of the type whose behavior isshown in FIG. 1A. The game program can be stored in a non-transitorygame software memory 18. System 1 further includes a graphics engine 19that generates graphics for display on the display 12. The system 1 isnot limited to a single processor or memory, but can comprise multi-corearchitecture, multiple processors and/or multiple memories, and/orremotely accessed network (e.g., cloud) computing components. Input frominput device 14 can affect/control program execution.

The graphics engine 19 includes a frame buffer memory that composesimages periodically at a frame rate (e.g., every 1/30^(th) or 1/60^(th)of a second) and reads out the images for display on the display 12.Frame refresh rate may be controlled by a timer that interrupts theprocessor 16 periodically or non-periodically.

The computing system 10 can further include an analyzer 20 used ingathering the program execution data when the processor 16 executes asoftware program. The analyzer 20 can be implemented in any combinationof software, hardware, and firmware. In one non-limiting illustrativeembodiment, the analyzer 20 is a form of a software profiler thatmonitors a sequence of operations performed by the processor 16 whilethe processor executes the software program. The analyzer 20non-intrusively samples the processor 16 program executions at variousrates and timings. The analyzer 20 collects data, which may specifyvarious functions that are called during the execution of the softwareprogram, and their addresses, which in turn indicate where in the memoryprogram the instructions are stored, as well as counts of timesparticular functions are called. The analyzer 20 can store the collecteddata in a non-transitory log memory buffer 21.

The system 1 also includes a software analysis device 30 (or informationprocessing apparatus 30) capable of communicating with the computingsystem 10 via a communications device 33, for example. The analyzer 20of the system 10 collects analysis data that is stored in the log memorybuffer 21 of the system 10 and this data can be conveyed to the softwareanalysis device 30. The software analysis device 30 is also configuredto have a processor 31 for processing data for analyzing the executionof a software program and a non-transitory memory 32 capable of storinga program for analyzing the execution of a software program. Likewise,the device 30 can be in communication with an input 14′ and a display12′ (or display device 12′).

The analysis device 30 is also configured to have an analyzer 34 thatcan analyze the dynamic program behavior of a software program based onthe analysis data provided from the computing system 10. It should beappreciated that any of the components shown in system 30 could also beincorporated in system 10 as well as on a remote system (e.g., in thecloud).

Display 12 may output audio/video data from the program being executedon system 10, where display 12′ can display a visualization of theanalysis being performed by device 30. For example, a user can play avideo game using system 10 where the game is displayed on display 12while device 30 analyzes the gameplay and displays a visualization of atimeline display on display 12′. The technology is not limited toseparately displaying these items and the same information can beconveyed on a single display or across a multitude of displays.

Example Non-Limiting Story Mode

The technology herein generates an abstract code execution timeline fromrepetitive programs, such as video games and simulations. This timelinemay be referred to herein as “Story Mode,” or “Story View,” since ittells a story of how the program executes over the course of a frame.This abstract code execution timeline can then be used to facilitateprogram comprehension, such as for the purposes of modifying the code toimprove execution speed, debugging, or other improvements.

FIGS. 3-7 show a non-limiting example of different views of exampleabstract code execution timelines that system 1 can produce. The viewscan be output on a display, such as display 12′, for example, stored innon-transitory memory 32 for communications, or later use, etc.

The view in FIG. 3 shows the Top Functions TF executed during a Frame FR(e.g., the top n functions such as, for example, 43 functions from aprofile out of several thousand sample functions), based on their numberof inclusive samples recorded (highest at the top in this example). Tothe right of each function name are Samples Runs SR (or executionevents) which are a graphical depiction of the sample runs that wererecorded with respect to a given frame. For example, the “dark” barsindicate a Sample Run SR of execution history for the particularfunction where the “light” spaces in between the “dark” bars indicatethat the function is not currently being processed/accessed. Thetimeline shown in FIG. 3 displays the graphical depiction for the top 43functions A-QQ (of potentially out of 1000 or more functions executingduring the Frame FR).

In the example shown, the timelines are ordered from top to bottom basedon function activity—that is, the amount of time (e.g., number ofsamples) during which the particular function is active. For example,function A is the most active function depicted in FIG. 3.

Within example Frame FR, function A is executing during most of theframe with a few hiatus, non-execution intervals. For example, functionA begins executing before the beginning of Frame FR during an executionperiod 1001, then ceases execution for a short time period 1003 beforeresuming execution during a subsequent execution period 1005. Similarly,function A ceases execution for an even shorter time period 1007 beforeresuming execution again during execution period 1009. This patterncontinues to nearly the end of the frame through execution periods 1013,1017, 1021, 1025 with corresponding hiatus or non-execution periods1015, 1019, 1023, 1027 of varying lengths interleaved therebetween. Itshould be appreciated that the non-execution periods 1015, 1019, 1023,1027 could be periods where the function is not executing (i.e., not beaccessed/called) or periods where the function is being interrupted by,for example, input/output operation.

As one can note, function B has nearly or exactly the same executionpattern as function A. Similarly, function C as shown in FIG. 3 hasnearly or exactly the same execution patterns as functions A and B.Thus, one can visually infer from the stacked timeline display or graphof FIG. 3 that functions A, B and C may be closely related, and allexecuted during most of the time of Frame FR.

Reading down the graph from the top, the first function that has adifferent execution pattern from the functions A, B and C is function D.Function D in this example appears to begin executing at the beginningof Frame FR during execution period 1029, executes for a short time, andthen ceases execution for a short non-execution time 1031 beforebeginning execution again during execution period 1033. Note that inthis particular example, the non-execution time 1031 of function Dappears to line up in time coincidence with non-execution time 1003 offunction A. Note further however that as one reads across the graph ofFIG. 3 from left to right, function D appears to follow the sameexecution pattern as functions A-C for a while but then about two-thirdsinto the frame time, function D has a shorter execution period 1035 thatbegins with function A execution period 1017 but then ceases abouthalfway in the middle of execution time 1017. When function D ceasesexecution period 1035, it is not called again for the remainder of FrameFR.

One can also see reading further down from the top of the FIG. 3 graphthat functions E and F have a similar execution pattern to function Dwith some difference. For example, function E has a very short executionperiod 1036 as opposed to a longer execution period 1029 of function D,and function E has no such corresponding execution period at all.

Reading further down the FIG. 3 graph, function G appears to beginexecution during execution period 1037 that begins after functions D, Eand F cease execution. Function G continues to execute for most of theremainder of the frame with three gaps between having differentnon-execution periods. Functions H and I bear some similarity tofunction G but are not identical in that they execute for shorterperiods even though they have at least one execution period that appearsto be in common with function G.

Reading further down the FIG. 3 graph from the top, function J has asingle execution period 1039 that occurs at approximately the center ofFrame FR. It is called only once and is not called again. Similarly,function K has a single execution period 1041 that begins aboutone-quarter of the time into Frame FR and appears to cease just beforefunction J begins executing. Function L has a single execution time 1043that is shorter than the execution times of either function K orfunction J (this is why this particular graph function L is orderedbelow functions J and K) which appears to start at about the same timeas function J's execution time 1039 but ends slightly earlier.Similarly, one can see unique execution patterns for functions M and Nand so on.

Looking at FIG. 3, the eye can see that there is some time correlationbetween the execution times of these various functions. Listing them inthe order shown and lining them up by coinciding their execution timesin this way allows a skilled person to discern certain patterns andconcurrency. However, the ordering of the processes in this example canobfuscate some important information. For example, the order in whichfunctions A-C are presented draws the eye to the top three lines butthere is very little additional information conveyed by the separatetimelines of functions B and C since their execution times appear to beidentical to the execution time of function A. Additionally, note thatthe order presented by the FIG. 3 graph (where the particular functiontimeline appears in a sequence determined by the percentage of executiontime for example) leads to some confusion. For example, function G onlyexecutes near the end of the Frame FR, whereas function W executes rightat the beginning of the frame. However, in the FIG. 3 graph, the eyereading the graph from top to bottom will see function G before functionW even though function W executed long before function G during FrameFR.

FIG. 4 shows the same Top Functions TF (i.e., functions A-QQ), butreordered chronologically and hierarchically to show a reorderedtimeline view of the execution of the various functions. Thus, a userwill be able to more easily understand the execution of a program duringa particular frame by visualizing which functions are executed at whattime and for how often during the Frame FR.

In the example shown in FIG. 4, the Top Functions TF show a certainorganization as to which function sample runs are executed during theFrame FR. For example, functions A-C have sample runs spanning theentire Frame FR where the remaining functions D-JJ have samples for onlya portion of the Frame FR. Also, the visualization displays theexecution/sample runs for functions D-JJ descending from top to bottomas the samples execute and display from left to right.

It should be appreciated that during the execution of a program, certainfunctions may execute in parallel with other functions. This isespecially true in modern day multi-core processing. Likewise, certainfunctions may call substantially related “child” functions to otherfunctions. In the example shown in FIG. 4, functions A-C shown inSimilar Function Group SFG1 call related “child” functions wherefunctions W and X in Similar Function Group SFG2 call related “child”functions.

Compared to FIG. 3, the illustrative example FIG. 4 graphicalpresentation has reordered all of the functions based upon when theyfirst execute during the Frame FR. Hence because functions A-C areexecuting at the very beginning of the Frame FR, they appear first onthe top three timelines of the graphical presentation. Similarly,functions D and E appear in the same position that they were shown inFIG. 3 because they also execute at or near the beginning of Frame FR.However, in the FIG. 4 example shown, functions W, X and Z appear nextreading from top to bottom because they also execute near the beginningof Frame FR and before, for example, function F. In the FIG. 4 exampleshown, function F appears next because it begins executing soon afterfunctions W, X and Z begin executing, and then the next function thatappears is function EE because it begins executing next. One can seethat the FIG. 4 example graphical presentations can be morecomprehensible in telling a story than the one shown in FIG. 3. Inparticular, one can see that functions W, X and Z begin executing earlyin the frame, followed by function F, function EE, function FF, and thenfunctions K, U, GG and LL all execute next and so on.

In the example shown in FIG. 4, certain functions executing within asame time period are ordered based on varying levels of prioritization.For example, function C has an earlier left-most starting time comparedto function D so function C should be ordered above function D. That is,even though functions C and D have a same right-most “ending” time,function C is listed higher due to its earlier “start” time. Likewise,nearing the end of execution for function D, functions C and D start ata same time (e.g., during frame 1035 shown in FIG. 3) but as function Chas a farther right-most ending time, function C would still be shownhigher in order than function D. Thus, as one “tie-breaking” condition,the system will determine which function should list higher based on itsleft-most start time or right-most end time. Should the functions havenearly the same execution during a sampling period (e.g., functions A-Cshown in FIG. 4), the system can look to the program call stack todetermine which functions actually execute more than others during thattime.

Although FIG. 4 can be more useful and comprehensible than FIG. 3, thereis still a fair amount of redundancy. In particular, for example,functions A, B and C tell essentially the same story and yet they areall presented in a way that adds to the overall complexity of thepresentation. This is a bit like telling a story of three friends who goon a walk together by first explaining what friend A did, thenexplaining in the same detail what friend B did and finally explainingin the very same detail what friend C did. Once you know the story ofwhat friend A did, you pretty much know what friends B and C did sinceall three were walking together. While this may be very useful for someuses, it may be desirable to simplify the story as much as possible inorder to convey the big picture to the user.

FIG. 5 thus shows a “pruned” set of functions from FIG. 4 where similarchildren are excluded. That is, the functions shown in FIG. 5 arerepresentative of function calls during Frame FR where several functionsfrom functions A-QQ are excluded by virtue of having similar childrenaccessed by the functions.

For example, functions B and C from Similar Function Group SFG1 areomitted where only function A is displayed. Likewise, function X inSimilar Function Group SFG2 is omitted where function W is displayed.Pruning the set of functions in this manner is advantageous because itaids in the understanding of the overall processing of the programduring Frame FR without showing functions that duplicate function callsand processes of other functions (i.e., to eliminate redundantfunctions).

FIG. 5 also shows the listing of functions visualized in a manner suchthat the functions are ordered from top to bottom based on chronologicalexecution, where the functions executing more frequently are displayedhigher in the order. As described above, FIG. 5 can be more useful andcomprehensible than FIG. 4 in that functions having similar childrenwith regard to execution are omitted thus eliminating “redundant”functions from the visualization. Thus, FIG. 5 shows the process ofexecution over the Frame FR where the duration of execution for eachfunction is shown from left to right along an axis of the display wherethe chronological execution of the function with respect to the otherfunctions in the visualization is ordered from top to bottom.

FIGS. 6 and 7 show a select group of functions. FIG. 6 shows a set offunctions selected and sorted with an “include parent” option disabledwhere FIG. 7 shows a set of functions selected and sorted with the“include parent” function enabled.

In FIG. 6, Select Functions SF are displayed showing the sample runsfrom left to right and the functions that are called during the Frame FRover time from top to bottom. As will be explained in further detailbelow, the functions in this example are called over two general groups.For example, functions E-C from Select Functions SF are called/sampledwithin Function Call Group FCG1 where functions L-U from SelectFunctions SF are called/sampled within Function Call Group FCG2.

As a non-limiting example, FIG. 6 could show the execution process of aset of functions over time during a Frame FR of execution therebyvisualizing how the function is called over time. For example, theprogram during Frame FR may first call function E for a period of timein which function R is called next. The program would continue bycalling functions R-U where certain functions may be called more thanonce during the frame (e.g., functions A, C, L).

As also explained above, the various gaps in function execution couldrepresent that the function is being called several times during thatparticular frame. The gaps can also represent the function beinginterrupted. For example, function H, as shown in FIG. 6, is beingcalled once during the Frame FR, but being interrupted several times(e.g., by input/output interrupts). Thus, the visualization can alsodepict to a viewer that the execution of function H is being interruptedfor some reason during its execution for this frame.

FIG. 6 can show the execution of a program over a given Frame FR wherethe duration of each function is displayed from left to right and thefunctions are ordered from top to bottom chronologically (i.e., by whenthey are called during execution of this frame). In FIG. 6, thevisualization shows a more condensed story of program execution. Thelevel of detail could be user customized and the user can see moreselect functions or less select functions depending upon the desiredlevel of detail. For example, a user could variably select the number offunctions that are to be displayed (e.g., functions 1-n) or the storymode could be pre-set. As an example, the system could have a “briefstory” option where approximately 10 functions are listed therebycondensing the story of function execution during frame FR. Likewise,the system could show a “full story” option where more functions arelisted giving more detail (e.g., 20 functions). The system could go intoeven more detail and provide a “fine story” option giving effectivelydrilling down farther into the function execution (e.g., 40-50functions). The functions shown in FIGS. 6 and 7 are selected based uponcertain threshold percentages that could also be user defined and thesethreshold values are discussed further below with respect to FIG. 12.

FIG. 7 thus shows the Select Functions SF executed over Frame FR fromFIG. 6, but also including the parent functions. For example, functionEE is representative of Parent Function PF1 for function E as ChildFunction CF1.

In the example shown in FIG. 7, the Function Call Groups FCG1 and FCG2convey to a user that three parent functions (functions EE, RR, WW) arecalled during the first grouping of functions where a single parentfunction (function LL) is called during the second grouping offunctions. Thus, functions E, R, W, H, Z, Y, A, and C are called duringthe first grouping by a combination of functions EE, RR, WW wherefunctions L, T, A, B, and U are called during the second grouping byfunction LL. It should be appreciated that the function parents shown inFIG. 7 will have a more generic name in the actual visualization wherethe child functions will have a more descriptive name.

Similar to FIG. 6, FIG. 7 could show the execution process of a set offunctions over time during a Frame FR of execution thereby visualizinghow the function is called over time. FIG. 7 though includes parentfunctions EE, RR, WW which could show how child functions E-U are calledduring execution of the program during Frame FR. For example, functionEE could be a parent function to several child functions where the firstchild function called by function EE is function E. As the programexecutes over the frame, parent functions could call several childfunctions. In the example shown in FIG. 7, functions EE, RR, and WWsubstantially run during the first grouping of functions and severalchild functions (i.e., functions E, R, W, H, Z, Y, A, and C) are calledduring that time. Likewise, function LL substantially runs during thesecond grouping of functions and several child functions (i.e.,functions L, T, A, B, and U) are called during that time.

It should be appreciated that, although FIGS. 3-7 show the visualizationof functions in black and white, the functions could be color coded foreasier understanding of function execution. For example, a color paletteof 16 colors could be used to color code functions A-QQ in FIG. 3 wherefunction A could have color blue, function B could have color red,function C could have color yellow, and so on.

FIG. 8 shows a non-limiting example flowchart depicting overallprocesses for generating a code execution timeline. The system 1 beginsby recording a statistical sampling profile with function call stacks(S101). For example, analyzer 20 can periodically stop the runningprogram (e.g., 50,000 times per second) and the current call stack canbe recorded in buffer 21.

With the recorded statistical sampling profile, the system 1 cancalculate and store the number of inclusive samples per function (S102).As a non-limiting example, the number of inclusive samples per functioncould be a number of recorded call stack samples that contain thefunction.

The system 1 can also use the recorded statistical sampling profile tocalculate and store contiguous sample runs per function (S103). The newdata can be stored per function and contain a list of runs, noting astart time and an end time for each run.

The system 1 can further use the recorded statistical sampling profileto construct a function call tree (S104). The tree, in a non-limitingexample implementation, can be a connected graph of nodes, with eachnode representing a function. In creating the tree, the system 1 cantake each recorded call stack sample and combine the information togenerate the call tree. For each node in the call tree, the number oftimes it appeared in a recorded call stack can be stored, for example,in memory 32. This is sometimes referred to as a number of “inclusive”samples because it represents a sample where execution stopped insidethat function or within a function it called.

Upon constructing the function call tree, the system 1 can determine ifthe abstract should be created using top functions or representativefunctions (S105). The option can be set, for example, by a user via auser interface. If the top functions option is selected the system 1 canselect functions based on a highest number of inclusive samples recordedduring the profile (S106). If the representative functions option wasselected, the system 1 can select the functions that are based on therange of inclusive samples recorded during the profile (S109).Regardless of the option, the system 1 will sort the functionschronologically and hierarchically (S107) and then display a final setof selected sorted functions (S108).

FIG. 9 shows a non-limiting example of a flow of processes for selectingfunctions based on a highest number of inclusive samples duringprofiling. The system 1 begins by sorting all of the sampled functionsby the number of inclusive samples during the profile (S201). The system1 then selects the top functions having the highest number of inclusivesamples (S202) where the exact number of functions may be configurable(e.g., by a user). For example, the system 1 could be configured to showthe top 50 functions having the highest number of inclusive samples.

Upon selecting the top functions, the system 1 determines whether itshould exclude similar function children based on the call tree (S203)and proceeds to exclude similar children if so (S205). The detailsregarding the exclusion of similar children are discussed below.

If the system 1 determines that it will not exclude similar children,the system 1 then determines if similar parents based on the call treeshould be excluded (S204). If the system 1 determines that similarparents should be excluded, the system 1 then executes a process forexcluding similar parents (S206) which is discussed further below. Upondetermining if either (or both) the similar children and similar parentsshould be excluded, the system 1 will create the final function list(S207).

FIG. 10 shows a non-limiting example embodiment of a flowchart showingprocesses for excluding similar children during tree traversal. Thesystem 1 begins by establishing a call tree and a selected functionslist (S301) where a backup copy of the selected function list is made(S302).

An IsMember variable can be set for each selected function in thefunctions list, where the initial value of IsMember is set to TRUE(S303). The IsMember variable is useful in helping identify whichfunctions in the call tree are members of the selected functions listwhich expedites processing.

The system 1 can, for each selected function (S304), reference the calltree and verify that all of the function's children are not members ofthe selected function list by checking the function's “IsMember”variable (S305). If, for the selected function, all children are notmembers, the system 1 will add the selected function to a “leaves list”(S306) which will be used to traverse the tree. The system 1 willcontinue to traverse through the selected functions repeating thisprocess (S304).

When all of the functions have been analyzed (S304), the system 1 willdetermine if the “leaves list” is not empty (i.e., having a number inthe list greater than 0) (S307). If the “leaves list” is empty (or ifthe “leaves list” has no more functions to analyze), then the IsMembervariable for each function in the backup list is set to FALSE in orderto reset the bookkeeping for later analysis (S308). If the “leaves list”is not empty, the system 1 will then pop functions from the “leaveslist” (S309). If the popped function's “IsVisited” variable is set toTRUE, the system 1 will return to see if the “leaves list” is now empty(S307). If the “IsVisited” variable is set to FALSE, the function's“IsVisited” variable is set to TRUE (S311) and the function is analyzed.

More specifically, the system 1 determines, for each parent of thefunction based on the call tree (S312), if the “IsMember” variable forthe parent is set to FALSE (S313). If the variable is set to FALSE, thesystem 1 moves on to the next function's parent (S312). If the variableis set to TRUE, the system 1 determines if the parent function issimilar to the child function (S314). In a non-limiting exampleimplementation, two functions can be similar if the number of inclusivesamples is within a threshold of each other (e.g., 50% or 99% similar).The similarity threshold could optionally be set by a user. If they aresimilar, then the parent function and the child function are bothmembers of the selected function list and thus it can be desirable tokeep the parent function and eliminate the child function. The system 1will thus set the child function's “IsMember” variable to FALSE (S316)and the child function will be removed from the selected function list.In either case, the system 1 will push the parent function on to the“leaves list” and continue the process for each parent (S312). Once allof the parents have been considered, the system 1 returns back todetermine if the “leaves list” is now empty (S307) where the processesmay be repeated if the list is still not empty.

FIG. 11 shows a non-limiting example embodiment of a flowchart showingprocesses for excluding similar parents during tree traversal. Thesystem 1 begins by establishing a call tree and a selected functionslist (S401) where a backup copy of the selected function list is made(S402).

As described above, an “IsMember” variable can be set for each selectedfunction in the functions list, where the initial value of “IsMember” isset to TRUE (S403). The IsMember variable is useful in helping identifywhich functions in the call tree are members of the selected functionslist which expedites processing.

The system 1 can, for each selected function (S404), reference the calltree and verify that all of the function's parents are not members ofthe selected function list by checking the function's “IsMember”variable (S405). If, for the selected function, all parents are notmembers, the system 1 will add the selected function to a “roots list”(S406) which will be used to traverse the tree. The system 1 willcontinue to traverse through the selected functions repeating thisprocess (S404).

When all of the functions have been analyzed (S404), the system 1 willdetermine if the “roots list” is not empty (i.e., having a number in thelist greater than 0) (S407). If the “roots list” is empty (or if the“roots list” has no more functions to analyze), then the IsMembervariable for each function in the backup list is set to FALSE in orderto reset the bookkeeping for later analysis (S408). If the “roots list”is not empty, the system 1 will then pop functions from the “roots list”(S409). If the popped function's “IsVisited” variable is set to TRUE,the system 1 will return to see if the “roots list” is now empty (S407).If the “IsVisited” variable is set to FALSE, the function's “IsVisited”variable is set to TRUE (S411) and the function is analyzed.

More specifically, the system 1 determines, for each child of thefunction based on the call tree (S412), if the “IsMember” variable forthe child is set to FALSE (S413). If the variable is set to FALSE, thesystem 1 moves on to the next function's child (S412). If the variableis set to TRUE, the system 1 determines if the child function is similarto the parent function (S414). In a non-limiting example implementation,two functions can be similar if the number of inclusive samples iswithin a threshold of each other (e.g., 50% or 99% similar). Thesimilarity threshold could optionally be set by a user. If they aresimilar, then the child function and the parent function are bothmembers of the selected function list and thus it can be desirable tokeep the child function and eliminate the parent function. The system 1will thus set the parent function's “IsMember” variable to FALSE (S416)and the parent function will be removed from the selected function list.In either case, the system 1 will push the child function on to the“roots list” and continue the process for each child (S412). Once all ofthe children have been considered, the system 1 returns back todetermine if the “roots list” is now empty (S407) where the processesmay be repeated if the list is still not empty.

FIG. 12 illustrates a non-limiting example embodiment of a flowchartdepicting a selection of functions within an inclusive range duringprofiling. The system 1 begins by traversing the call tree functionsstarting at the root (S501) and determines if the traversed function'sinclusive percentage is greater than or equal to a minimum value (S507).As a non-limiting example, the inclusive percentage could be thefunction's inclusive sample count divided by the number of samplesrecorded where the minimum value could optionally be user defined (e.g.,1% or 0.1%). If the function's inclusive percentage is less than theminimum value, the recursion will cease (S517). If the percentage isgreater than or equal to the minimum value, the system 1 determines ifthe function is a leaf node in the call tree and if it's inclusivepercentage is greater than a maximum value (S509). If the inclusivepercentage is greater than a maximum value, the system 1 defines aprocess to traverse the call tree from the leaf function to find themost representative function that is similar to the leaf function withinsome threshold percentage (S502). If the inclusive percentage is lessthan or equal to the maximum (S510) value, the system 1 can perform anoptional step of determining if the function period matches the framerate (S512). If the function period matches the frame rate, the system 1can optionally determine if the function is periodic (S513).

If the function is determined that it should not be included in theabstract (S511), the system 1 determines if the function is a leaf nodewhere recursion will cease (S517) and if it is not a leaf node, thesystem 1 will continue recursion for each of the function's child nodes(S508) meaning that each child function should spawn off for furtherprocessing (S507).

In defining the process to traverse the call tree from the leaf function(S502), the system 1 assigns the variable “LeafInclusive” with thefunction's inclusive percentage and assigns the variable “NewFunction”with the current function (S503). If the “NewFunction” parent'sinclusive percentage is within a variable percentage of “LeafInclusive”(where the variable percentage can be user defined, for example, 5%)(S504), the system 1 traverses up the call tree by assigning thevariable “NewFunction” with “NewFunction” parent function (S505) andrepeats the determination if “NewFunction” parent's inclusive percentageis within a variable percentage of “LeafInclusive” (S504). If the“NewFunction” parent's inclusive percentage is not within a variablepercentage of “LeafInclusive” (S504), the system 1 assigns “Function”with the function held in “NewFunction.”

The system 1 can then add the function to the abstract if it is notalready a member of the abstract (S514) and then continue to optionallydetermine if the parent should be included (S515). If the parentfunction should be included, the parent function will be added to theabstract if it is not already a member of the abstract (S516) whererecursion will then cease (S517).

FIGS. 13 and 14 show a non-limiting example of functions with multiplesample runs across multiple frames. FIG. 13 shows an example of a startof a run in frame 2 where a frame start time (S601) is shown at 0.05 mswhere the sample run (S602) is shown as “Function A” with a start of runin frame 2 (S603). FIG. 14 shows an example of an end of a run withinframe 2 where the sample run (S701) begins in frame 1 but ends asdepicted by “Function A” in frame 2 (S702).

FIG. 15 shows a non-limiting example embodiment of a flowchart for aprocess for computing the start time and end time of a run for aparticular frame for each function, as shown by example in FIGS. 13 and14. The system 1 begins by, given the recorded frames, selecting acertain frame start time to base the chronological sorting (S801). Forexample, in FIG. 13 the start of frame 2 at 0.05 ms (S601) could beselected to base the chronological sorting.

The system 1 then, for each function (S802), examines each of thefunction's runs (S803). A run can be defined as a contiguous series ofsamples that include the same function. An example of a single run(S602) is shown in FIG. 13. For each run (S803), if the start time ofthe run is greater than or equal than the frame start time (for example,as shown in S603 of FIG. 13), or if the end time of the run is greaterthan or equal to the frame start time (for example, as shown in S702 ofFIG. 14), then the system 1 assigns the function's “Start of Run thisFrame” to the “Start Time of Run” and assigns the function's “End of Runthis Frame” to the “End Time of Run” (S805). If neither of these testsare affirmative, the system 1 continues for each function run (S803).Once all of the functions have been examined (S802), the process iscomplete and all of the functions have been assigned time values for“Start of Run this Frame” and “End of Run this Frame.”

FIG. 16 depicts a non-limiting example embodiment of a flowchart for aprocess of comparing two functions to create a sorted list. Theprocesses determine how functions compare with each other and one ofordinary skill would understand that a list of items can be sorted ifthere is a method to compare any two items in the list. The examplesshown in FIG. 16 show a first function (Function X) and a secondfunction (Function Y). If Function X is less than Function Y, thenFunction X should appear in the final sorted list before Function Y andvice-versa. FIG. 16 depicts the process for comparing Function X andFunction Y.

The system 1 begins by determining if the X start of the run is lessthan the Y start of the run (S901), then X<Y. Otherwise, the system 1will determine if the X start of the run is greater than the Y start ofrun (S902), then X>Y. If X start of run is not greater than Y start ofrun, the system 1 determines if X end of run is greater than Y end ofrun (S903), then X<Y. If not, then the system 1 determines if X end ofrun is less than Y end of run (S904), then X>Y.

If the system 1 does not determine either for X end of run and Y end ofrun, the system 1 determines if X's stack depth in the call tree is lessthan Y's stack depth in the call tree (S905), then X<Y. If X's stackdepth in the call tree is greater than Y's stack depth in the call tree(S906), then X>Y. If the system 1 does not determine either for X stackdepth and Y stack depth, then the system 1 determines if X's number ofinclusive samples is greater than Y's number of inclusive samples(S907), then X<Y. If X's number of inclusive samples is less than Y'snumber of inclusive samples (S908), then X>Y. If the system 1 does notdetermine for X and Y's number of inclusive samples which is greater,than X=Y.

While the technology has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the technology is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements.

At least the following is claimed:
 1. A method performed by at least oneprocessor for analyzing video game execution, the method comprising:maintaining a record of execution of one or more functions of the videogame during a frame of video game execution; selecting a subset of theone or more functions based on at least activity of the record ofexecution of the selected functions; sorting the selected subset offunctions based on both chronological order of execution andhierarchical function calling relationships indicated by the record offunction execution; and generating, using the at least one processor, atimeline display having a first axis for the selected and sorted subsetof functions and having a second axis for graphically depicting functionexecution over time, the timeline display showing function clusters ofvideo game execution over time in an order showing diagonally along thetimeline display relative to the first and second axes.
 2. The methodaccording to claim 1, wherein the sample runs for each function aredisplayed in a first color when the function is being accessed for aportion of time during the frame of program execution and a second colorwhen the function is not being accessed for the period of time duringthe frame of program execution.
 3. A method implemented in aninformation processing apparatus having one or more processors forgenerating a code execution timeline, the method comprising: recording,from an interactive program executing one or more functions, executionhistories of the one or more functions being accessed in the interactiveprogram, the interactive program configured for execution on, at least,a video game system; sorting the functions based at least in part on acriteria related to function execution; and generating, via the one ormore processors, a timeline display having a first axis for the sortedfunctions and having a second axis for graphically depicting functionexecution over time, the timeline display showing, at least, functionclusters of program execution, associated with the interactive program,over time in an order showing diagonally along the timeline displayrelative to the first and second axes.
 4. The method of claim 3, furthercomprising: displaying a list of functions on a first axis of thetimeline display; and displaying, next to each respective function alonga second axis of the timeline display, at least one execution event foreach function in the list of functions, the generated timelinesdisplayed such that the timelines contain the list of functions and theat least one execution event for each function.
 5. The method of claim4, further comprising: selecting a group of functions from the one ormore functions; displaying the selected group of functions in thetimeline display; and modifying the timeline display to remove displayof one or more functions having similar execution from the selectedgroup of functions.
 6. The method of claim 5, wherein the one or morefunctions having similar execution call one or more similar childfunctions.
 7. The method of claim 4, further comprising: selecting arepresentative group of functions from the one or more functions; andmodifying the timeline display to exclude parent functions from theselected representative group of functions.
 8. The method of claim 4,further comprising: selecting a representative group of functions fromthe one or more functions; and modifying the timeline display to includeparent functions from the selected representative group of functions. 9.The method of claim 4, wherein each function in the timeline display canbe displayed in a color different from at least one other function. 10.The method of claim 3, wherein the functions are sorted based on both achronological order of execution and hierarchical function callingrelationship indicated by the record of function execution.
 11. Anon-transitory computer-readable storage medium comprising instructionswhich, when executed by one or more processors of an informationprocessing apparatus, cause the information processing apparatus to:record, from an interactive program executing one or more functions,execution histories of the one or more functions being accessed in theinteractive program, the interactive program configured to execute on asystem configured for video game functionality; sort and filter thefunctions based at least in part on a criteria related to functionexecution; and generate a timeline display having a first axis for thesorted and filtered functions and having a second axis for graphicallydepicting function execution over time, the timeline display showing, atleast, function clusters of program execution, associated with theinteractive program, over time in an order showing diagonally along thetimeline display relative to the first and second axes.
 12. Thenon-transitory computer-readable storage medium of claim 11, wherein theinformation processing apparatus is further caused to: display a list offunctions on a first axis of the timeline display; and display, next toeach respective function along a second axis of the timeline display, atleast one execution event for each function in the list of functions,the generated timelines displayed such that the timelines contain thelist of functions and the at least one execution event for eachfunction.
 13. The non-transitory computer-readable storage medium ofclaim 12, wherein the information processing apparatus is further causedto: select a group of functions from the one or more functions; displaythe selected group of functions in the timeline display; and modify thetimeline display to remove display of one or more functions havingsimilar execution from the selected group of functions.
 14. Thenon-transitory computer-readable storage medium of claim 13, wherein theone or more functions having similar execution call one or more similarchild functions.
 15. The non-transitory computer-readable storage mediumof claim 12, wherein the information processing apparatus is furthercaused to: select a representative group of functions from the one ormore functions; and modify the timeline display to exclude parentfunctions from the selected representative group of functions.
 16. Thenon-transitory computer-readable storage medium of claim 12, wherein theinformation processing apparatus is further caused to: select arepresentative group of functions from the one or more functions; andmodify the timeline display to include parent functions from theselected representative group of functions.
 17. A system, comprising: aprocessing system having a memory and one or more processors, theprocessing system configured to: record, from an interactive programexecuting one or more functions, execution histories of the one or morefunctions being accessed in the interactive program, the interactiveprogram configured for execution using an information processing systemthat is capable of providing video game functionality, selectively sortand filter the functions based at least in part on a criteria related tofunction execution, and generate a timeline display having a first axisfor the sorted and filtered functions and having a second axis forgraphically depicting function execution over time, the timeline displayshowing, at least, function clusters of program execution, associatedwith the interactive program, over time in an order showing diagonallyalong the timeline display relative to the first and second axes. 18.The system of claim 17, wherein the processing system is furtherconfigured to: display a list of functions on a first axis of thetimeline display; and display, next to each respective function along asecond axis of the timeline display, at least one execution event foreach function in the list of functions, the generated timelinesdisplayed such that the timelines contain the list of functions and theat least one execution event for each function.
 19. The system of claim18, wherein the processing system is further configured to: select agroup of functions from the one or more functions; display the selectedgroup of functions in the timeline display; and modify the timelinedisplay to remove display of one or more functions having similarexecution from the selected group of functions.
 20. The system of claim19, wherein the one or more functions having similar execution call oneor more similar child functions.
 21. The system of claim 18, wherein theprocessing system is further configured to: select a representativegroup of functions from the one or more functions; and modify thetimeline display to exclude parent functions from the selectedrepresentative group of functions.
 22. The system of claim 18, whereinthe processing system is further configured to: select a representativegroup of functions from the one or more functions; and modify thetimeline display to include parent functions from the selectedrepresentative group of functions.